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© A method of managing a telecommunication 
subnetwork system composed of a number of net- 
work elements coupled together through an optical 
medium to form a Synchronous Optical NETwork 
(SONET) ring. Each of the network elements re- 
ceives upon initiation or reconfiguration and then 
stores an identical ring table or knowledge database 
that is composed of data in a predetermined format 
and structure. The ring table defines the ring type 
and ring identification, number of nodes, ring status, 
node identification, sequence, and status, and pro- 
vides ring provisioning tables and embedded 
SONET ring path identification/status information. 
The ring table is utilized in each of the network 
elements for provisioning and other management 
type functions common within a SONET ring envi- 
ronment. 
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The present invention is directed in general to 
a telecommunication subnetwork system, and, 
more particularly, to a method of managing a 
SONET ring subnetwork through the use of a ring 
table that is embedded into each network element 
of the ring. 

In telephone communications in the past, 
voice/data was carried primarily over metallic me- 
dia such as twisted pair and coaxial cable. Over 
metallic media, voice/data is transferred at a speed 
or line rate of various levels. For example, the 
human voice can be carried as a digital signal at a 
line speed of 64 kilobits per second (kbps). For this 
line speed, the voice signal must be sampled 8,000 
times each second, and using pulse code modula- 
tion, each voice value is carried as an eight-bit 
sample. This 64 kbps rate is called the Digital 
Signal level 0, or DS-0, rate. Higher rates, such as 
DS-1, DS-2, DS-3, ... DS-N also exist, and are 
described in the International Telegraph and Tele- 
phone Consultative Committee (CCITT) Recom- 
mendations G.703. However, the speed at which 
data is transferred over metallic media is limited. 
To overcome this limitation, optical fiber media 
have been developed, which can accommodate 
much higher line speeds, and hence can transfer 
much more information in a given period of time. 

The development of optical fiber transmission 
systems resulted in the Synchronous Optical NET- 
work or SONET standard, which is a Northern 
American version of SDH (Synchronous Digital 
Hierarchy). SONET defines a line rate hierarchy 
and frame format, and is fully described by the 
American National Standards Institute (ANSI) speci- 
fication for a high-speed digital hierarchy for optical 
fiber communications in ANSI T1.105 and T1.106. 

The SONET line rate hierarchy is based upon 
transmission building blocks of 51.84 million bits 
per second (Mbps) each. The 51.84 Mbps rate is 
called the Synchronous Transport Signal level 1 
(STS-1), which is the basic logical building block. 
Higher rates or levels are all multiples of the basic 
rate of 51.84 Mbps, for example, the STS-3 rate is 
155.52 Mbps. In general, the different line rates of 
the electrical signals are referred to as an STS-N 
rate. The different line rates of the optical signals 
corresponding to the electrical signals are referred 
to as OC-N. 

The frame format for STS-N line rates is de- 
rived from a basic unit of transport for the STS-1 
frame, which is organized into nine rows of 90 
bytes or 810 bytes per frame. Each frame is gen- 
erated 8,000 times per second (8 KHz), yielding 
the 51.84 Mbps STS-1 rate (i.e., 8000 
frames/second * 810 bytes/frame * 8 bits/byte). By 
now, those skilled in the art are well familiar with 
the SONET standard, and thus further description 
thereof will be omitted. 
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Referring now to Fig. 1a, there is shown a high- 
level architecture of a typical telecommunication 
subnetwork system including a SONET ring 1, 
which is a collection of nodes or network elements 

5 (throughout this specification the terms "node" and 
"network element" are used interchangeably) N(1), 
N(2), ... N(n) coupled together by optical fiber 2 to 
form a closed loop. The nodes N(1), N(2) are 
coupled to an operation support system (OSS), 

w which performs the general telecommunication 
functions. 

The. nodes or network elements N(1) to N(n) 
are SONET add-drop multiplexed (ADM) providing 
access to all or at least a subset of the STS path 

75 signals contained within an OC-N optical channel of 
the optical fiber 2. As described later on in more 
detail, STS or VT (virtual tributary) signals are 
added to (inserted) or dropped from (extracted) the 
OC-N signal as it passes through the individual 

20 add-drop multiplexed nodes. 

SONET rings can be divided into two general 
categories, namely, line switched and " path 
switched according to the protection mechanism. 
Further, according to the direction of the traffic flow 

25 under normal working conditions, these categories 
are divided into unidirectional and bidirectional sub- 
categories. 

A line switched architecture uses SONET line 
layer indications to trigger the protection switching 

30 action. Switching action is performed at only the 
line layer to recover from failures, and does not 
involve path layer indications. Line layer indications 
include line layer failure conditions and signaling 
bit-coded messages that are sent between nodes 

35 to effect a coordinated line protection switch. In the 
event of a failure, line switched rings establish ring 
switches at the two nodes adjacent to the failure. In 
addition, four-fiber bidirectional line switched rings 
may have the capability of using span switching. 

40 A path switched ring include two counter-rotat- 

ing fibers, each of which forms a two-way commu- 
nication path. The duality of complete two-way 
paths is used to protect each other at any given 
time. The incoming tributary from the low speed 

45 side is permanently bridged at the node where it 
enters the ring and is transmitted in both directions 
over the different fibers to the node where the 
channel is dropped from the ring. At this node one 
of the two signals is selected as working. The 

50 trigger mechanism for the protection switch is de- 
rived from information in the SONET path layer. 

In a unidirectional path switched ring, normal 
routing of the working traffic is such that two way 
communication signals travel around the single fi- 

55 ber of the ring in the same direction (e.g., clock- 
wise). Specifically, the two way communication sig- 
nals use capacity along the entire circumference of 
the ring. 

2 
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Fig. 2 illustrates a unidirectional, two-fiber path 
switched SONET ring. The SONET ring has, for 
example, five nodes N(1) to N(n), which are inter- 
connected by a unidirectional, two-fiber path having 
working W and protection P p^ths. In the unidirec- 
tional SONET ring, the incoming and outgoing data 
follow the same direction on the ring. 

Figs. 3a and 3b illustrate a bidirectional two- 
fiber and four-fiber line switched SONET ring, re- 
spectively. Here, normal routing of the working 
traffic is in both directions. That is, traffic traverses 
a ring normally carried on the working channels, 
except in the event of a ring or span protection 
switch, in which case it is restored on the protec- 
tion channels. 

In the two-fiber ring of Fig. 3a, a first optical 
fiber OF1 includes first working W1 and protection 
P1 channels and a second optical fiber OF2 in- 
cludes second working W2 and protection P2 chan- 
nels. In the four-fiber ring of Fig. 3b, the four 
optical fibers OF1 to OF4 form two pairs of bidirec- 
tional optical fibers, one pair being used for bidirec- 
tional working channels W1 , W2, and the other pair 
being used for bidirectional protection channels P1, 
P2. 

In a SONET ring configured in one of the 
manners described above, the transfer of data 
throughout the ring must be provisioned to achieve 
Time Slot Assignment (TSA), Time Slot Inter- 
change (TSI), and all cross connections between 
the line side and add-drop side for each of the 
nodes in a ring. Generally, these ring provisioning 
techniques are carried out by many cross connec- 
tion commands issued from the OSS to each of the 
individual nodes or network elements as shown in 
Fig. 1a. 

A more recent requirement or demand from 
telecommunication service providers is that the 
provisioning process be performed by the individ- 
ual network elements in response to provisioning 
information or commands provided by the OSS or 
other network management tools. This is common- 
ly termed autoprovisioning. 

Another requirement for SONET ring telecom- 
munication subnetwork systems is that of automatic 
protection switching. Currently, in known telecom- 
munication systems, the amount of provisioning 
information that is stored at each of the network 
elements is quite limited. For instance, according 
to one method, single cross connection assignment 
information is stored in each of the network ele- 
ments. In this method, because the individual net- 
work elements only have isolated single termination 
assignment information, each of the individual 
cross connections is treated as an entity. In a 
second method, each network element includes 
cross connection information for a single node so 
that the node is treated as a managed entity. Both 
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of these methods, however, are disadvantageous in 
that they rely on a centralized OSS to provision the 
individual network elements of the SONET ring. 
In a telecommunication subnetwork system, 

5 such as that shown in Fig. 1a for example, all 
intelligence of the network management system 
resides primarily in the OSS. A subnetwork man- 
agement layer is missing from the architectures 
known today. Moreover, in most cases, the network 

io elements are simply "dummy" equipment and 
have little or no management functions at all. In 
other words, the OSS manages all operations and 
functions of the network elements by communicat- 
ing commands to each of the network elements 

15 individually. As a result, the OSS is under a heavy 
burden to manage each of the individual network 
elements. 

Thus, if this methodology in which the OSS is 
under a heavy burden to manage each of the 

20 individual network elements continues, it will lead 
to inefficient operation of the OSS and the SONET 
ring as a whole. Moreover, as the telecommunica- 
tion subnetwork increases in size, as more SONET 
ring and/or individual network elements are added, 

25 and as more functions and services are provided, 
the OSS will not be able to manage the network in 
an effective manner. 

As new SONET ring technologies and architec- 
tures evolve, the traditional network management 

30 methods will not be adequate. For example, a 
SONET ring must provide support for self-healing, 
autoprovisioning, software/firmware download, and 
provide quick responses to network management 
requests. The current centralized management 

35 method, which places a heavy burden on the OSS 
to meet all of these needs, is simply not adequate. 

Thus, without partitioning and distributing the 
network management functions to the subnetwork 
and network element level, the situation will be- 

40 come even worse. There is thus a need to change 
from a more centralized to a more distributed man- 
aged network. The present invention as described 
herein meets this and all other requirements men- 
tioned above. 

45 Accordingly, it is a general object of the 

present invention to provide a distributed knowl- 
edge database for each node of a SONET ring 
which is free of the above and other problems of 
the prior art. 

50 ' Another object of the present invention is to 
partition and distribute the network management 
functions to the subnetwork in order to realize a 
more distributed managed network. 

Yet another object of the present invention is to 

55 provide a distributed management method by us- 
ing a ring table which is adaptable to highly sophis- 
ticated SONET characteristics and SONET ring ar- 
chitecture by utilizing a data communication chan- 

3 
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nel, Section DCC; this method being more ad- 
vanced than what is presently known in the prior 
art. 

It is a further object of the present invention to 
support many advanced network functions, such as 
autoprovisioning, self-healing protection switching, 
the use of protection channels to carry extra traffic, 
and other advanced network management functions 
in SONET ring applications. In addition, more net- 
work management functions can be easily imple- 
mented by using the ring table. These functions 
include status monitors at ring level, path level, and 
node level, ring information database synchroniza- 
tion, etc. 

The above and other objects of the present 
invention are accomplished by providing a method 
of managing a synchronous optical network 
(SONET) ring composed of a plurality of network 
elements coupled together through an optical fiber 
medium in which a plurality of channels are de- 
fined, each of the network elements comprising 
first and second high-speed interface modules for 
interfacing the network elements to one another 
through the optical fiber medium, and a low-speed 
interface module selectively coupled to the first 
and second high-speed interface modules. The 
method includes steps of generating a ring table 
comprising data representing ring characteristics 
for each of the network elements of the SONET 
ring, the ring characteristics including, for each of 
the network elements of the SONET ring, ring 
provisioning information for defining channel con- 
nectivities between the first and second high-speed 
interface modules and for defining channel connec- 
tivities between the low-speed interface module 
and each of the first and second high-speed mod- 
ules of the SONET ring, downloading the ring table 
to each of the network elements, storing the ring 
table in each of the network elements, and man- 
aging each of the network elements of the SONET 
ring according to the ring tabie. 

In further accordance with the above and other 
objects, the present invention provides a telecom- 
munication subnetwork system including transmis- 
sion means including an optical fiber medium for 
transferring OC-N data, and a SONET ring network 
comprising a plurality of network elements coupled 
together through the transmission means to form a 
closed loop. Each of the plurality of network ele- 
ments include first and second high-speed inter- 
face modules for interfacing the network element to 
the transmission means, the first and second high- 
speed interface modules comprising means for 
converting optical signals OC-N to electrical signals 
STS-N and electrical signals STS-N to optical sig- 
nals OC-N, at least one low-speed module, coupled 
to the first and second high-speed modules and to 
a communication device located outside of the 
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SONET ring network, means for storing a ring 
table, the ring table comprising data representing 
ring characteristics for each of the network ele- 
ments of the SONET ring, the ring characteristics 

5 including, for each of the network elements of the 
SONET ring, ring provisioning information for defin- 
ing channel connectivities between the first and 
second high-speed interface modules and for defin- 
ing channel connectivities between the low-speed 

ro interface module and each of the first and second 
high-speed modules of the SONET ring, and a 
controller for controlling and managing the transfer 
of data to and from each of the network element 
within the SONET ring in accordance with the ring 

/5 table. 

Fig. 1a illustrates a hierarchial architecture of a 
conventional telecommunications subnetwork sys- 
tem. 

Fig. 1b illustrates a hierarchial architecture of a 
20 telecommunications subnetwork system according 
to the present invention. 

Fig. 2 illustrates a unidirectional, two-fiber path 
switched SONET ring having five nodes intercon- 
nected by a unidirectional, two-fiber path having 
25 working W and protection P paths. 

Figs. 3a and 3b illustrate a bidirectional two- 
fiber and four-fiber line switched SONET ring, re- 
spectively. 

Figs. 4a-4e illustrate a portion of a ring table 
30 according to the present invention. 

Fig. 5 illustrates a four node, two-fiber BLSR 
type SONET ring. 

Fig. 6 is an example of a ring provisioning 
table, which is a key component of the ring table, 
35 for the clockwise working channels STS#1-STS#6 
of the four node, two-fiber BLSR SONET ring of 
Fig. 5. 

Fig. 7 illustrates the different types of cross- 
connections at a node between two high speed 
40 sides and a low speed side. 

Fig. S illustrates a ring provisioning table for 
the counter-clockwise working channels of the ring 
of Fig. 5. 

Fig. 9a illustrates the ring provisioning table for 
45 the counter-clockwise (CCW) protection channels 
STS#7 to STS#12 which carry extra traffic before a 
failure. 

Figs, 9b and 9c illustrate the ring provisioning 
table for the clockwise (CW) working channels 
50 STS#1 to STS#6 and the counterclockwise (CCW) 
protection channels STS#7 to STS#12 of the ring 
of Fig. 5 before and after a failure. 

Fig. 10 illustrates a functional block diagram of 
a network element. 
55 Fig. 1 1 illustrates a functional block diagram of 

a controller from the network element of Fig. 10. 

According to the present invention, a ring 
knowledge database (herein "ring table") is com- 

4 
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posed of data that provides complete ring sub- 
network provisioning information and other man- 
agement information for the entire ring. The ring 
table provides the necessary intelligence for the 
individual network elements and is used by the 
network elements for decision making processes 
in, for example, autoprovisioning and self-healing 
operations, as well as other management functions. 
The consolidated ring table is also, used by the 
management system for simplifying operations of 
the SONET ring as a whole. 

The ring table is updated, as necessary, 
through network element to network element and/or 
network element to OSS communications using 
standard communication protocols and messages. 
As will become clear to the skilled artisan, the ring 
table is capable of supporting SONET ring man- 
agement functions including not only autoprovision- 
ing, ring automatic protection switching (APS) and 
carrying extra traffic, but also other ring network 
management functions, such as ring performance 
monitoring, ring alarm surveillance, etc. The in- 
formation provided by the ring table and its asso- 
ciated algorithm permits the SONET ring table to 
evolve to a high-level managed object. 

Although the description herein focuses on the 
application of a ring table for a SONET ring, it will 
be clear to one of ordinary skill in the art that such 
a ring table can easily be implemented to support 
multiple telecommunication management network 
functions, such as those defined in CCITT Rec- 
ommendation M.30, Principles for a Telecommuni- 
cation Management Network, and ANSI T1-210 
America National Standard for Telecommunications 
Operation, Administration, Maintenance, and Provi- 
sioning (OAM&P) - Principle of Functions, Architec- 
tures, and Protocols for Interfaces between Oper- 
ations systems and Network Elements. 

According to the present invention, a SONET 
ring is provisioned using a ring based method that 
treats the ring as a managed entity and manages a 
ring at the subnetwork level through each node of 
the ring. It provides a subnetwork management 
layer and automates the ring management func- 
tions. The ring based method provides a more 
systematic way to manage a SONET ring as a 
whole rather than managing separately each of the 
many individual nodes and links within the ring 
subnetwork. As this method results in more intel- 
ligence being embedded into each of the ring 
network elements, the ring network elements can 
advantageously perform ring management func- 
tions with minimum human intervention. 

Before providing a detailed description of the 
ring table, reference is made to Figs. 10 and 11 
which illustrate functional block diagrams of a net- 
work element. Fig. 10 shows a functional block 
diagram of a SONET network element N(n), while 
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Fig. 11 illustrates a functional block diagram of a 
controller. 

Referring first to Fig. 10, the network element 
100 includes a pair of high speed function blocks 

5 101, 10V, processing functional block 102. a NM 
communication module 103, a controller 104, low- 
speed unit 105, and a power/clock functional block 
106. The high-speed functional blocks 101, 10V 
are respectively coupled to the optical media 2 that 

to interfaces adjacent nodes to one another. The high 
speed functional blocks therefore include optical 
high speed interface units for sending and receiv- 
ing optical signals, for example, OC-12, OC-48. 
The functional blocks 101, 10V also serve to con- 

75 vert the optical signals to STS electrical signals, or 
STS electrical signals to optical signals. The low- 
speed unit 105 includes a series of add/drop 
boards BRD1 to BRDn, which serve as interfaces 
to lower speed devices, such as OC3, OC1, STS1, 

20 DS3, DS1, etc. 

The processing function block 102 serves 
many functions for a network element, and includes 
a unit 102(a) for multiplexing, demultiplexing, and 
time slot assignment and interchange of the add 

25 and drop signals that are received from or sent to 
the high-speed modules 101, 10V and low-speed 
unit 105, a switching unit 102(b) for protecting the 
network elements, and a NM overhead (e.g., 
SONET overhead) processing unit 102(c). 

30 The NM communication 103 provides a further 

interface to additional data communication chan- 
nels, such as X.25, LAN to OSS, or OSS related 
equipment including subnetwork controller media- 
tion device. The controller 104 provides for the 

35 general network management information process- 
ing and control of the network element. A more 
detailed functional block diagram of the controller 
104 is illustrated in Fig. 11. Lastly, the power and 
clock function block 106 provides power and cloc- 

40 king signals to the other components of the net- 
work element. 

Referring to Fig. 11, the controller 104 includes 
a hardware module 120 which is composed of, for 
example, a central processing unit (CPU) for pro- 

45 viding the overall control of the network element, a 
memory 121, which interacts closely with the CPU 
in storing working data including the ring table as 
defined below, and a control input/output port 122 
for interfacing with the other components of the 

so network element. The CPU executes control pro- 
grams which are generally stored in a general 
software storage or memory/interface unit 123. The 
memory /interface unit 123 is also coupled to an 
interface to SONET NM overhead unit 124 in order 

55 to receive and process embedded SONET over- 
head from the NM overhead module of the pro- 
cessing unit 102. The memory/interface unit 123 
further interfaces with an interface to NM commu- 
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nication unit 125 for receiving or sending mes- 
sages/data from or to an OSS or subnetwork con- 
troller which are present when additional data com- 
munication channels are present as provided for by 
the NM communication unit 103 shown in Fig. 10. 

Fig. 1b illustrates an embodiment of a tele- 
communication subnetwork system including a 
SONET ring in which the present invention is car- 
ried out. Specifically, the system of Fig. 1b in- 
cludes at least three levels, namely, the OSS with 
distributed intelligence, a subnetwork controller 
SNC at a second level, and intelligent network 
elements N'(1) ... N'(n) at a third level. In contrast 
to more conventional systems such as that shown 
in Fig. 1a, the SNC provides subnetwork layer and 
network layer management functions, such as filter- 
ing, grouping, ring management, etc. 

During the initiation or reconfiguration of a 
SONET ring, a ring table is downloaded through a 
communication channel or section DCC channel 
and is stored in the memory 121 in each of the 
network elements. 

Figs. 4a-4e illustrate an example of a portion of 
the ring table, which is of a predetermined format 
and data structure. The table as shown in Fig. 4 
defines the ring type and ring identification (ID), 
number of nodes, ring status, node identification 
(ID), sequence, and status. As described below the 
ring table also includes ring provisioning tables and 
embedded SONET ring path identification/status 
information. 

Specifically, Fig. 4a illustrates the format and 
data structure for the ring ID and ring type data 
fields. The ring ID is defined by two bytes of ASCII 
characters, and the ring type is defined by one 
byte of data. In the ring type data field, the first 
nibble identifies the type of ring, such as UPSR or 
BLSR, and the second nibble indicates the number 
of fibers (e.g., two or four). 

The ring status data field is illustrated in Fig. 
4b and is defined by two bytes of data. For in- 
stance, the two bytes of ring status are based on 
the SONET overhead K1, K2 bytes of data for a 
BLSR type of ring. On the other hand, for a UPSR 
type of ring, a zero indicates normal non-switching 
status, while a non-zero indicates the amount of 
path switching that is currently taking place. 

Figs. 4c and 4d illustrate the data structure 
defining the number of nodes and node sequence. 
In Fig. 4c, one byte of data is used to identify the 
number of nodes. In this embodiment, a SONET 
ring can have up to 255 nodes. The node se- 
quence is defined by a table that lists each node ID 
in a particular sequence. A node status byte of 
information is provided for each of the nodes on 
the SONET ring as shown in Fig. 4e. The node 
status code represents predefined conditions, such 
as no alarm, a major alarm, or a minor alarm. 
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Lastly, with reference to Fig. 6, the ring table 
includes a SONET ring provisioning table. The pro- 
visioning table is a three-dimensional array includ- 
ing rows of data for defining channel information in 

5 a BLSR application and path information in a UPSR 
application, and one column including two add-drop 
subcolumns per node for defining the node and 
connection type information. 

Fig. 5 illustrates an example of a four node, 

io two-fiber BLSR type SONET ring. One of the two 
fibers carries traffic in the clockwise (CW) direction, 
while the other fiber carries traffic in the counter- 
clockwise (CCW) direction. In the disclosed em- 
bodiment, each of the fibers include 12 channels 

75 including channels 1-6, which are used as working 
channels for carrying normal traffic, and channels 
7-12, which are used as protection channels for 
restoring normal traffic when a node failure or fiber 
cut occurs. Otherwise, the protection channels 7-12 

20 do not carry normal traffic, but they may carry 
extra traffic. Extra traffic is the traffic that is carried 
over the protection channels when they are not 
used for the protection of the traffic on the working 
channels. Extra Traffic is not protected, and if the 

25 protection channels are required to protect or re- 
store the working traffic, the extra traffic is pre- 
empted. 

Fig. 6, which is described in more detail below, 
is an example of a ring provisioning table for the 

30 clockwise (CW) working channels 1-6 of the four 
node, two-fiber BLSR of Fig. 5. The six channels 
are labeled as STS#1 - STS#6. Typically, there 
would be four tables, one for each of the channel 
groups: CW working channels 1-6; CW protection 

35 . channels 7-12; CCW working channels 1-6; and 
CCW protection channels 7-12 generated and 
stored in the memory 121 of the controller. For 
bidirectional channels, the table for the CW chan- 
nels is the same as the table for the CCW channels 

40 except the directions are opposite. 

The maximum SONET STS-1 bidirectional 
paths that can be assigned to the BLSR ring is 
equal to six times the number of nodes. That is, in 
BLSR type rings, each segment between two 

45 nodes may signal independently if the traffic pat- 
terns are ail with neighboring nodes. Therefore, the 
maximum number of paths will depend on the 
traffic pattern; the more traffic between the neigh- 
boring nodes, the more paths will necessarily be 

so assigned to different segments of the ring. In gen- 
eral, however, the total number of paths that could 
be utilized will be between six times the number of 
nodes and 12 bidirectional STS-1 channels de- 
pending on the traffic pattern. 

55 For UPSR type applications, the ring table is 

much simpler due to the fixed in and out traffic 
pattern. For instance, for a two-fiber OC-12 UPSR, 
only a maximum of 12 SONET STS-1 paths can be 

6 
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assigned to the UPSR ring because all bidirectional 
channels traverse the entire ring. Therefore, each 
STS-1 channel can only be assigned once. 

Fig. 6 illustrates an example of a ring provision- 
ing table for the clockwise (CyV) working channels 5 
STS#1 - STS#6 of the four node, two-fiber BLSR 
SONET ring of Fig. 5. The ring provisioning table 
for the CW working channels includes a column for 
each of the nodes A, B, C, and D, and each 
column includes an ADD and DROP column. There w 
is also one row for each of the six channels labeled 
as STS#1, STS#2, STS#3, STS#4, STS#5, and 
STS#6. Fig. 6 shows in particular the provisioning 
of one-way normal traffic which is carried by the 
CW working channels STS#1 - STS#6 in the left to 75 
right direction. 

As described above, the ring provisioning table 
includes a row for each channel and a column 
including two subcolumns for each node. Cross- 
connection information, which determines the con- 20 
nections between the channels entering and exiting 
the node and the add/drop connections between 
the high-speed unit and low-speed units, in the 
form of a ring path Id is inserted into selective cells 
defined by the rows and by the ADD and DROP 25 
columns. The ring path ID is a unique character 
string to identify a particular SONET path within a 
SONET ring. The characters are chosen to be 
meaningful to associated nodes, especially the 
starting or source node and the ending or destina- 30 
tion node. A sequence number may be used to 
make each path ID unique (the sequence numbers 
do not have to be consecutive). In addition, an 
extension number is used to indicate the low speed 
board sequence where the signal is added from or 35 
dropped to. For example, ring path ID "AD2" (see 
Fig. 6) indicates a path which starts at node A and 
ends at node D. The extension number "-2" of the 
path ID "AD2" at node A indicates that low speed 
board sequence number 2 is where the signal is 40 
added at node A. The extension number "-1 " of 
the path ID "AD2" at node D indicates that the 
signal is dropped to the low speed board BRD1 at 
the ending node D. A second extension can also 
be utilized to indicate the status of the path. 45 

There are four possible types of cross-connec- 
tions, namely, ADD, DROP, DROP-CONTINUE, and 
PASSING THROUGH. These four cross-connec- 
tions are represented in the provisioning tables by 
the following nomenclature: 50 

ADD - Path ID (e.g., AC1) appears in the ADD 
column and not the DROP column of a node (e.g., 
node A). The extension number, e.g., "-1 " of the 
path AC1, indicates the sequence of the low speed 
board from which the signal is added. Here, the 55 
board sequence number is 1 . 

DROP - Path ID appears in the DROP column 
and not the ADD column of a node (e.g., AB3-2 at 
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node B). The extension number is used to indicate 
the low speed board sequence at which the signal 
is dropped. 

DROP AND CONTINUE - Path ID appears in 
both the DROP and ADD columns of a node (e.g., 
BA4-4 and BA4-0 in the DROP and ADD columns 
of node D). The extension number of the path ID in 
the DROP column indicates the low speed board 
sequence at which the signal is dropped, while the 
extension number of the path ID in the ADD col- 
umn is always M -0" to indicate that no low speed 
board is used for continuing the signal. 

PASSING THROUGH - Path ID appears only in 
the ADD column of a node and the extension 
number is always "-0". The extension number is 
always "-0" to indicate that no low speed board is 
used to add or drop the passing through signals. 

Fig. 7 illustrates each of the different types of 
cross-connections at node B between two high 
speed sides and a low speed side. Boards BRD1- 
BRD5 of the low-speed unit represent typical 
add/drop boards used for interfacing to lower 
speed (e.g., DS-N) devices. Specifically, referring 
to Fig. 7, the channel STS#1 is dropped to the low 
speed board BRD1 and continued, the channel 
STS#2 passes through node B, the channel STS#3 
is dropped to the low speed board BRD2, and the 
channel STS#4 is added from the low speed board 
BRD3 to the high speed line side at node B. 

The ring table also supports both TSAs and 
TSIs for SONET Ring applications. Specifically, in 
a BLSR application, TSAs and TSIs are both sup- 
ported. Between high speed sides, TSAs and TSIs 
are supported by locating the same path ID (e.g., 
BA4 in Fig. 6) in different rows of the table. The 
extension (e.g., "-3") is used to indicate the con- 
nection to/from the low speed board, while the 
extension "-0" is used to indicate a PASS- 
THROUGH type connection. Thus, TSAs and TSIs 
are also supported between high speed and low 
speed sides. 

In a USPR application, the ring table provides 
the capability of low speed port assignment, which 
is very useful. For example, the ring table supports 
a path that may be dropped to different low speed 
boards by changing the board/port ID number or 
the extension of the path ID. The table also sup- 
ports TSIs between high speed sides and low 
speed sides. 

Referring to Fig. 6, the ring provisioning table 
provides the following SONET ring path provision- 
ing and node provisioning information. 

The SONET ring path provisioning information 
derived from the Fig. 6 is as follows: 
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PATH AC1 

The SONET ring path AC1 represents the path 
which extends from node A to node C and there- 
fore is labelled as AC1. The number "1" of the 
label "AC1" is used to uniquely identify this path 
within the ring. As illustrated in Fig. 6, the path AC1 
is added from the low speed board BRD1 to the 
channel STS#1 at node A, and is dropped and 
continued at node B. In the DROP column at node 
B, the extension "-1" indicates the low speed 
board BRD1. In the ADD column, the extension "- 
0" (i.e., no low speed board is used for adding) 
indicates that the path AC1 continues. Because the 
path AC1 is in both the DROP and ADD columns 
and in the same row (i.e., the channel STS#1), 
there is no time slot assignment change of this 
path at node B. Finally, the path AC1 is dropped to 
the board BRD1 at node C. 

PATH AD2 

The SONET ring path AD2 extends from node 
A to node D. The number "2" of the path label 
"AD2" uniquely identifies this path from the other 
paths of the SONET ring. The path AD2 is added 
from the low speed board BRD2 at node A to the 
channel STS#2, and is passed through at node B 
(denoted by the label AD2-0 in the ADD column; 
the "-0" extension indicating that no low-speed 
board is used). The path AD2 is also passed 
through at node C with no low-speed board being 
necessary, and finally the path AD2 is dropped 
from STS#2 to the low speed board BRD1 at Node 
D. The path AD2 does not undergo any STS time 
slot changes at any of the nodes. 

PATH AB3 

The path AB3 extends around the SONET ring 
from node A to node B. The number "3" of the 
label "AB3" is used to uniquely identify this path 
within the ring. The path AB3 is added from the low 
speed board BRD3 at node A to the channel 
STS#3, and is dropped to the low speed board 
BRD2 at node B from the channel STS#3. 

PATH CD6 

The path CD6 runs from node C to node D 
around the ring. The number "6" of the label 
"CD6" is used to uniquely identify this path within 
the ring. At node C, the path CD6 is added from 
the low-speed board BRD2 to the channel STS#4, 
and, at node D, the path CD6 is dropped to the 
low-speed board BRD2 from the channel STS#4. 



PATH CD7 

The path CD7 is added from the low-speed 
board BRD3 at node C to the channel STS#5, and 
5 is dropped to the low speed board BRD3 at node D 
from the channel STS#5. The number "7" of the 
label "CD7" is used to uniquely identify this path 
within the ring. 

io PATH BA4 

The path BA4 extends around the SONET ring 
from node B to node A. The number "4" of the 
label "BA4" is used to uniquely identify this path 

75 within the ring. Specifically, the path BA4 is added 
from the (ow-speed board BRD3 at node B, is 
passed through and reassigned to the channel 
STS#6 from the channel STS#4 at node C, is 
dropped to the low speed board BRD4 and contin- 

20 ued on channel STS#6 at node D, and is finally 
dropped from the channel STS#6 to the low-speed 
board BRD4 at node A. 

The node provisioning information derived from 
Fig. 6 is as follows: 

25 

NODE A 

At node A, the path AC1 is added from the low 
speed board BRD1 to the channel STS#1, the path 
30 AD2 is added from the low speed board BRD2 to 
the channel STS#2, the path AB3 is added from 
the low speed board BRD3 to the channel STS#3, 
and the path BA4 is dropped from the channel 
STS#6 to the low speed board BRD4. 

35 

Node B 

At node B, the path AC1 is dropped from the 
channel STS#1 to the low speed board BRD1 and 
40 continued, the path AD2 is passed through at the 
channel STS#2, the path AB3 is dropped from the 
channel STS#3 to the low speed board BRD2, and 
the path BA4 is added from the low speed board 
BRD3 to the channel STS#4. The specific cross- 
es connections between the high speed sides and the 
low speed side at node B are illustrated in detail in 
Fig. 7. 

Node C 

50 

The path AC1 is dropped to the low speed 
board BRD1 from the channel STS#1, the path 
AD2 is passed through node C on the channel 
STS#2, the path CD6 is added from the low speed 
55 board BRD2 to the channel STS#4, and the path 
CD7 is added from the low speed board BRD3 to 
the channel STS#5. The path BA4 is reassigned at 
this node from the channel STS#4 to the channel 
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STS#6, because the channels STS#4 and STS#5 
are used between nodes C and D by the Paths 
CD6 and CD7. 

Node D 

At node D, the path AD2 is dropped to the low 
speed board BRD1 from the channel STS#2, the 
path CD6 is dropped to the low speed board BRD2 
from the channel STS#4, the path CD7 is dropped 
to the low speed board BRD3 from the channel 
STS#5, and the path BA4 is dropped to low speed 
board BRD4 from the channel STS#6 and contin- 
ued on the same channel STS#6. 

In addition to providing path provisioning in- 
formation and node provisioning information, the 
ring provisioning table also provides time slot inter- 
change (TSI) information. Specifically, in order to 
provide TSI information, the same SONET ring 
path ID will appear at different rows/time slots 
under the same column of a node to indicate that it 
was dropped from a first channel and added to a 
different channel. TSI information can also be in- 
dicated if a path is passed through on one channel 
at a node and switched to a different channel in an 
adjacent node. For example, the path BA4 at node 
B is on the channel STS#4 and changed to the 
channel STS#6 at node C, thus indicating a time 
slot interchange of the path BA4. Fig. 8 illustrates a 
ring provisioning table for the CCW working chan- 
nels STS#1 to STS#6. In contrast to the table for 
the CW working channels as shown in Fig. 6^the 
table of Fig. 8 illustrates the paths or the one-way 
traffic from right to left. It is also noted that the 
ADD and DROP columns are switched. 

In order to recognize the bidirectional paths 
(i.e., the path pairs) easily, the path IDs are trans- 
posed to indicate properly the source and final 
destinations. For example, paths AB3 and BA3, 
CD6 and DC6, etc. are path pairs. 

In order to explain the relationship between the 
working time slots and protection time slots after a 
failure (e.g., a fiber between nodes is cut or a node 
failure), reference to the provisioning tables of Figs. 
9a to 9c is made. Fig. 9a illustrates the ring provi- 
sioning table for the CCW protection channels 
STS#7 to STS#12 which carry extra traffic. Figs. 9b 
and 9c illustrate the ring provisioning table for the 
CW working channels STS#1 to STS#6 and the 
CCW protection channels STS#7 to STS#12. 

In general, prior to a failure, all protection chan- 
nels STS#7 to STS#12 in both the CW and CCW 
directions are most likely in a default status (i.e., 
passing through). When an optical cable has been 
cut or a node has failed, the working channels are 
looped back using the protection channels to re- 
store the traffic. Figs. 9b and 9c illustrate the 
manner in which the traffic on the CW working 
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channels is restored by the protection channels 
following a failure such as the optical fiber between 
node B and node C being cut as shown in Fig. 5b. 
In this example, the affected SONET paths AC1, 

5 AD2, and BA4 are looped back through the CCW 
protection channels STS#7, STS#8, and STS#10 to 
pass signals back to the other ends respectively. A 
specific advantage of the present invention is that 
not all of the protection channels between nodes 

w are necessary for restoring the traffic. That is, only 
the channels STS#7, STS#8, and STS#10 are re- 
quired in this example. In conventional systems, all 
protection channels STS#7 to STS#12 would be 
required to restore the traffic. 

/5 Typically, under normal conditions (i.e., no fail- 

ures) the CW and CCW protection channels STS#7 
to STS#12, which share the same fibers used for 
the working channels, do not carry normal traffic. It 
is common, however, for the protection channels to 

20 carry extra traffic as described above. In this in- 
stance, without the use of a ring table according to 
the present invention, all extra traffic must be 
dropped when a failure occurs because each node 
does not know which of the extra traffic can be 

25 saved. However, through the use of the SONET 
ring table as described herein, only a minimum 
number of protection channels is necessary to re- 
store the normal traffic. 

The rules for defining and using the ring provi- 

30 sioning table including the assignment and des- 
ignation of path IDs for the working traffic are also 
applicable to the extra traffic. The only difference 
between a working table and a protection table is 
the direction of the traffic. Thus, the ADD and 

35 DROP columns are transposed. 

More specifically, Fig. 9A illustrates the provi- 
sioning of extra traffic on the protection channels 
STS#7 to STS#12 in the CCW direction before a 
failure has occurred. Here, the extra traffic is car- 

40 ried on paths AB10, BA17, BA9, CA8, CB11, DA14, 
and DC12 across nodes A, B, C, and D. 
1 After a failure occurs, such as the optical cable 
between nodes B and C being cut, the protection 
channels STS#7, STS#8, and STS#10 are used to 

45 restore the traffic. Specifically, referring to Fig. 9B, 
the path AC1 is looped back at node B on the 
protection channel STS#7 as indicated by the lead 
line L1. The path AD2 is looped back at node B on 
the channel STS#8 as represented by the lead line 

so L2 t and the path BA4 is looped back on the chan- 
nel STS#10 as the lead line L3 represents. Other- 
wise, the protection channels STS#9, STS#11, and 
STS#12 are not disturbed and these channels con- 
tinue to carry extra traffic. Fig. 9c illustrates the 

55 provisioning table for the protection channels 
STS#7 to STS#12 after a failure has occurred. The 
paths AC1, AD2, and BA4 constitute the normal 
traffic that has been looped back along the protec- 

9 
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tion channels STS#7, STS#8, and STS#10, while 
the paths AB10, BA9, CB13, DA14, and DC12 
continue to carry extra traffic even after a failure 
occurs. In sum, after a failure, only extra traffic 
paths on the channels STS#7, STS#8, and STS#1 0 5 
are lost, and all other extra traffic are unaffected. 

It is also noted that in Figs. 9b and 9c, a 
second extension (e.g., "-L") is used to indicate 
that a path is being looped back. Further, for BLSR 
type rings, two characters L or B can be used to w 
indicate that a path is being looped back or 
bridged, respectively. For UPSR type rings, two 
characters N or S can be used to indicate that a 
path is normally selected or switched, respectively. 
However, it is clear to one of ordinary skill in the ;s 
art, more status characters can be utilized in order 
to indicate various other path conditions such as bit 
error related information for a particular path, etc. 

It is further noted that upon the occurrence of a 
failure, the ring table may be revised or modified to 20 
reflect the new provisioning of the paths. Alter- 
natively, the provisioning information can be deter- 
mined based on the provisioning information prior 
to the failure and the known protection switching 
that results when the failure is detected. 25 

Once the failure has been rectified (i.e., the 
hardware has been repaired), normal traffic is re- 
covered without reprovisioning the SONET ring. 
That is, after the failure has been rectified, the ring 
table stored in the nodes are utilized to recover or 30 
restore the normal traffic; even for the nodes di- 
rectly affected by the failure. If the failure causes a 
node to lose the ring table, that node can request 
and receive the ring table from a neighboring node 
(as the ring tables stored in each of the nodes are 35 
identical). Therefore, full recovery and auto- 
provisioning is realized after the hardware failure is 
eliminated. This recovery is performed without in- 
tervention from any outside management systems. 

It will become clear to those of ordinary skill in 40 
the art that a ring based management method 
according to the present invention as disclosed 
hereinabove has many advantages over conven- 
tional systems. In summary, the ring table serves 
primarily two purposes. First, the ring table simpli- 45 
fies the ring subnetwork management interface ex- 
ternally by reducing the number of interface com- 
mands that must be transferred between the in- 
dividual network elements and the OSS, for exam- 
ple. Second, the ring table can be used internally 50 
as a knowledge base for each of the ring network 
elements to perform intelligent tasks and support 
advanced features such as autoprovisioning, self- 
healing, and ring recovery. Because the manage- 
ment information is distributed over the ring, not 55 
only is the network management greatly improved, 
but the database synchronization problem is re- 
solved. Other advantages include the fact that only 



one ring download command is necessary for pro- 
visioning the entire ring, that each of the network 
elements receives the same information (i.e., ring 
table), and that the ring table can be updated 
through direct network element to network element 
communications within the ring. In all, the ring table 
supersedes the other methods and provides better 
ring support. 

There has thus been shown and described a 
novel SONET ring subnetwork management meth- 
od which fulfills all the objects and advantages 
sought therefor. Many changes, modifications, vari- 
ations and other uses and applications of the sub- 
ject invention will, however, become apparent to 
those skilled in the art after considering the speci- 
fication and the accompanying drawings which dis- 
close preferred embodiments thereof. All such 
changes, modifications, variations and other uses 
and applications which do not depart from the spirit 
and scope of the invention are deemed to be 
covered by the invention which is limited only by 
the claims which follow. 

Claims 

1. A method of managing a synchronous optical 
subnetwork (SONET) ring composed of a plu- 
rality of network elements coupled together 
through an optical fiber medium in which a 
plurality of channels are defined, each of said 
network elements comprising first and second 
high-speed interface modules for interfacing 
said network elements to one another through 
said optical fiber medium, and a low-speed 
interface module selectively coupled to said 
first and second high-speed interface modules, 
said method comprising the steps of: 

generating a ring table comprising data 
representing ring characteristics for each of the 
network elements of the SONET ring, said ring 
characteristics including, for each of the net- 
work elements of the SONET ring, ring provi- 
sioning information for defining channel con- 
nectivities between the first and second high- 
speed interface modules and for defining chan- 
nel connectivities between the low-speed inter- 
face module and each of the first and second 
high-speed modules of said SONET ring; 

downloading said ring table to each of the 
network elements; 

storing said ring table in each of said net- 
work elements; and 

managing each of said network elements 
of said SONET ring according to said ring 
table. 

2. A method of managing a SONET ring sub- 
network as defined by Claim 1, wherein said 
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ring characteristics comprise ring type and ring 
identification, number of nodes within the 
SONET ring, ring status, and node identifica- 
tion, sequence, and status. 

i 

3. A method of managing a SONET ring sub- 
network as defined by Claim 2, wherein the 
data representing the ring characteristics are 
dynamically updated to reflect current con- 
ditions of the SONET ring. 

4. A method as defined by Claim 2 or 3, 

wherein the ring type defines one of un- 
idirectional path switched ring (UPSR) and 
bidirectional line switched ring (BLSR), and the 
number of optical fibers within the optical fiber 
medium. 

5. A method as defined by any one of Claims 1 

to 4, wherein said ring provisioning in- 
formation for defining channel connectivities 
represents the connections between the chan- 
nels entering and exiting the first and second 
high speed modules of each of the network 
elements and add and drop connections be- 
tween the first and second high speed mod- 
ules and the low-speed interface module. 

6. A method of managing a SONET ring sub- 
network as defined by Claim 5, wherein the 
channel connectivities comprises data to de- 
fine ADD, DROP, DROP-CONTINUE, and 
PASS-THROUGH channel connections. 

7. A method as defined by any one of Claims 1 

to 6, 

wherein said managing step comprises the 
step of transferring normal traffic and extra 
traffic around the SONET ring to the first and 
second high-speed modules and the low- 
speed interface module of each of the network 
elements based on the ring provisioning in- 
formation. 

8. A method of managing a SONET ring sub- 
network as defined by Claim 7, wherein the 
SONET ring is a bidirectional line switched 
ring and the optical fiber medium includes first 
and second fibers, the first fiber carrying traffic 
in the clockwise (CW) direction and including 
CW working and CW protection channels, and 
the second fiber carrying traffic in the coun- 
terclockwise (CCW) direction and including 
CCW working and CCW protection channels, 
said method further comprising the steps of: 

defining a first type of channel connectivity 
information for each of the CW working, CW 
protection, CCW working, and CCW protection 



channels between the first and second high- 
speed modules of each of the network ele- 
ments; 

defining a second type of channel connec- 
5 tivity information for each of the CW working, 

CW protection, CCW working, and CCW pro- 
tection channels between the first and second 
high-speed modules and the low-speed inter- 
face module for each of the network elements; 
10 and 

generating the ring provisioning informa- 
tion based on the first and second types of 
channel connectivity information. 

r5 9. A method of managing a SONET ring sub- 
network as defined by Claim 8, wherein during 
normal conditions said CW and CCW working 
channels carry normal traffic and said CW and 
CCW protection channels carry the extra traf- 

20 fic, and during failure conditions said CW and 

CCW protection channels restore the normal 
traffic, said method further comprising the step 
of: 

recognizing a failure condition and the lo- 
25 cation of the failure condition within the 

SONET ring; 

identifying the CW and CCW working 
channels affected by the failure condition 
based on the ring provisioning information; 
30 identifying the CW and CCW protection 

channels not affected by the failure condition 
based on the ring provisioning information; and 
restoring the normal traffic carried on the 
CW and CCW working channels affected by 
35 the failure condition to the CW and CCW pro- 

tection channels not affected by the failure 
condition. 

10. A method of managing a SONET ring sub- 
40 network as defined by Claim 9, said method 

further comprising the step of modifying the 
ring provisioning information of said ring table 
after the normal traffic has been restored so as 
to define the channel connectivities for each of 
45 the CW working, CW protection, CCW working, 

and CCW protection channels. 

11. A method as defined by any one of Claims 1 
to 10, 

50 wherein said managing step comprises the 

step of transferring normal traffic around the 
SONET ring to the first and second high-speed 
modules and the low-speed interface module 
of each of the network elements based on the 

55 ring provisioning information. 

12. A method of managing a SONET ring sub- 
network as defined by Claim 11, wherein the 



11 



BNSDOCID: <EP 0645905A2_I_> 



21 



EP 0 645 905 A2 



22 



15. A method of managing a SONET ring network 
as defined by Claim 13 or 14, further compris- 
ing the step of recovering the normal traffic 
without reprovisioning the SONET ring. 

16. A method as defined by any one of Claims 1 
to 15, 

wherein the ring provisioning information 
for defining channel connectivities comprises 
an array of data cells, said array including a 
row for each of the channels and a column 
including two subcolumns for each network 
element of the SONET ring, and wherein se- 
lected ones of the data cells include ring path 
identification information to define the channel 
connectivities between the first and second 
high-speed interface modules and-for defining 
channel connectivities between the low-speed 
interface module and each of the first and 
second high-speed modules of said SONET 
ring. 



SONET ring further comprises an optical fiber 
for carrying traffic on clockwise (CW) working 
and CW protection channels in the CW direc- 
tion and for carrying traffic on counterclock- 
wise (CCW) working and CCW protection 5 
channels in the CCW direction, said method 
further comprising the steps of: 

defining a first type of channel connectivity 
information for each of the CW working, CW 
protection, CCW working, and CCW protection w 
channels between the first and second high- 
speed modules of each of the network ele- 
ments; 

defining a second type of channel connec- 
tivity information for each of the CW working, 15 
CW protection, CCW working, and CCW pro- 
tection channels between the first and second 
high-speed modules and the low-speed inter- 
face module for each of the network elements; 
and 20 

generating the ring provisioning informa- 
tion based on the first and second types of 
channel connectivity information. 



13. A method of managing a SONET ring sub- 
network as defined by Claim 12, wherein dur- 
ing normal conditions said CW and CCW work- 
ing channels carry normal traffic and said CW 
and CCW protection channels carry extra traf- 
fic, and during failure conditions said CW and 
CCW protection channels restore the normal 
traffic, said method further comprising the step 
of: 

recognizing a failure condition and the lo- 
cation of the failure condition within the 
SONET ring; 

identifying the CW and CCW working 
channels affected by the failure condition 
based on the ring provisioning information; 

identifying the CW and CCW protection 
channels not affected by the failure condition 
based on the ring provisioning information; and 

restoring the normal traffic carried on the 
CW and CCW working channels affected by 
the failure condition to the CW and CCW pro- 
tection channels not affected by the failure 
condition, 

14. A method of managing a SONET ring network 
as defined by Claim 13, said method further 
comprising the step of modifying the ring pro- 
visioning information of said ring table after the 
normal traffic has been restored so as to de- 
fine the channel connectivities for each of the 
CW working, CW protection, CCW working, 
and CCW protection channels. 



17. A method of managing a SONET ring sub- 
network as defined by Claim 16, wherein the 

25 ring path identification information comprises a 

unique character string of data to identify each 
SONET path within the SONET ring. 

18. A method of managing a SONET ring sub- 
30 network as defined by Claim 17, wherein the 

unique character string of data is associated 
with each of the network elements and iden- 
tifies the network element where the SONET 
path begins and the network , element where 
35 the SONET path ends, and includes a se- 

quence number for uniquely identifying the 
SONET path. 

19. A method of managing a SONET ring sub- 
40 network as defined by Claim 18, wherein the 

unique character string of data further com- 
prises a first extension character to identify the 
low-speed interface module that a SONET path 
is dropped to or added from. 

45 

20. A method of managing a SONET ring sub- 
network as defined by Claim 19, wherein the 
unique character string of data further com- 
prises a second extension character to identify 

50 the status of a SONET path. 

21. A telecommunication subnetwork system com- 
prising: 

transmission means including an optical 
55 fiber medium for transferring OC-N data; and 

a SONET ring network comprising a plural- 
ity of network elements coupled together 
through said transmission means to form a 
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closed loop, each of said plurality of network 
elements comprising: first and second high- 
speed interface modules for interfacing said 
network element to said transmission means, 
said first and second high-speed interface 
modules comprising means for converting op- 
tical signals OC-N to electrical signals STS-N 
and electrical signals STS-N to optical signals 
OC-N; 

at least one low-speed module, coupled to 
said first and second high-speed modules and 
to a communication device located outside of 
the SONET ring network; 

means for storing a ring table, said ring 
table comprising data representing ring char- 
acteristics for each of the network elements of 
said SONET ring, said ring characteristics in- 
cluding, for each of the network elements of 
said SONET ring, ring provisioning information 
for defining channel connectivities between the 
first and second high-speed interface modules 
and for defining channel connectivities be- 
tween the low-speed interface module and 
each of the first and second high-speed mod- 
ules of said SONET ring; and 

a controller for controlling and managing at 
least a portion of the OC-N data to and from 
each of said network element within said 
SONET ring in accordance with said ring table. 

22. The telecommunication subnetwork system as 
defined by Claim 21, wherein said SONET ring 
is configured as a unidirectional path switched 
ring. 

23. The telecommunication subnetwork system as 
defined by Claim 21 or 22, wherein said 
SONET ring is configured as a bidirectional 
line switched ring. 

24. The telecommunication subnetwork system as 
defined by Claim 23, wherein said transmission 
means comprises two optical fibers. 



defines one of unidirectional path switched ring 
(UPSR) and bidirectional line switched ring 
(BLSR), and the number of optical fibers within 
the optical fiber medium. 

5 

28. The system as defined by any one of Claims 
21 to 27, 

wherein said ring provisioning information 
for defining channel connectivities represents 

10 the connections between the channels entering 

and exiting the first and second high speed 
interface modules of each of the network ele- 
ments, and add and drop connections between 
the first and second high speed interface mod- 

75 ules and the low-speed interface module. 

29. The telecommunication subnetwork system as 
defined by Claim 28, wherein the channel con- 
nectivities comprises data to define ADD, 

20 DROP, DROP-CONTINUE, and PASS- 

THROUGH channel connections. 



25 



30 
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40 



25. The telecommunication subnetwork system as 
defined by Claim 23, wherein said transmission 
means comprises four optical fibers. 



45 



26. The system as defined by any one of Claims 

21 to 25, 50 

wherein said predetermined characteristics 
comprise ring type and ring identification, 
number of nodes within the SONET ring, ring 
status, and node identification, sequence, and 
status. 55 



27. The telecommunication subnetwork system as 
defined by Claim 26, wherein the ring type 
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